“用户故事地图”在TFS平台上的应用

本文主题

本文受徐磊老师的【构建高效DevOps团队培训课程】的启发，总结一下“用户故事地图”方法在TFS平台上的应用。

第一种方式是：
系统的需求工作项（长篇故事、特性和情景）直接和用户故事地图（活动、任务和子任务）做一一”直接映射”

第二种方式是： 做一下业务需求到技术实现的功能转换，将任务这一级直接转换到系统实现的功能上，具体可参见下文的“转化映射”

直接映射法

用户故事地图的层次不一定都是3层，也有可能是2层（如附录参考文章“创建用户故事地图”所演示例子），甚至多层。在TFS2015系统里默认支持3层，对应的层次名称是“长篇故事、特性和情景”（如果采用Agile模板）和 3层的用户故事地图做一一映射，如下图所示：

TFS平台的项目“用户故事地图”各层名称也可自定义叫其他名称“业务功能、系统功能、用户故事”，比如下图

还有一招小窍门特别好用，就是打开“映射”可以直接通过拖拽挂好各层之间的父子级关系，无需一个个点击链接添加：

挂第三层“用户故事”与第二层“用户任务”之间的关系

挂第二层“用户任务”与第一层“用户活动”之间的关系

在每一层的积压列表都可以看到全局的“用户故事地图”

转化映射法

这种方法是把原来业务上3层的“用户故事地图”通过区域的设定转换成2层的TFS“用户故事地图”，如下图所示通过在徐磊老师的“DevOps培训课程”中，我们制作了一个影响地图，并转换为可以实现的用户故事地图

经过分析，要实现“在一个月内营业额翻翻”这个有约束条件的目标，我们计划当前迭代只开发”抽奖”和“国庆促销”2个功能，由于是对已有系统进行业务开发，原有系统有前端、后台、首页等模块功能，因此我们只需在将第二层定义为区域，实现如下：

则这样用户任务层就转换成区域，变成了2层的用户故事地图，这样的好处是业务地图到技术地图有了更深的连接和转换。

类似的案例可以参考老师的培训教程：
样例项目背景

相关基础知识

「用户故事地图」介绍

「用户故事地图」是一种敏捷开发过程中建立共识的一种方法，可以在多类ALM、敏捷流程工具上进行实践，比如TFS，Jira等，它的核心作用是“增强团队协作，洞察真实需求，研磨优良产品”。

Martin Fowler说:“故事地图是一门在需求拆分过程中保持全景图的技术”。Kent Beck最早提出故事的目的是激发沟通的火花。他呼吁团队把沟通作为高效团队的核心价值。故事，是程序员和其他角色沟通的必备要求，故事地图将这些要素组织为结构化，以此来强化软件开发中最关键的部分 — 沟通。

Alan Cooper认为用户故事地图是连接开发和设计的桥梁。交互设计的核心是发现用户行为并像讲故事一样把它们描述出来。软件开发则是将这些描述拆分、实现并集成到产品中。通过用户故事地图的方式来处理用户故事，设计仍然保持其叙事结构，开发工作也可以得到很好的分解从而得以高效实现。

所以，您可以通过构建用户故事地图来形成产品的MVP（Most Valuable Product最小可行性产品），进行快速验证和迭代，从而给用户交付有价值的产品。

关于「用户故事地图」，我有幸拜读到了许多的专家和敏捷教练写的分享文章，都非常有见地(参见附录)，本文并不在此赘述。

「用户故事」的3C与5C原则，以及6个特性

此部分内容来自后面的参考文章“”

Ron Jeffries的3个C

用户故事，Ron Jeffries用3个C来描述它：

卡片（Card） – 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。 交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。 确认（Confirmation）- 通过验收测试确认用户故事被正确完成。

用户故事的增补5C原则

参考上面 Jeffries的3C，在此基础上补充2个C。

Construction(构建)

开始构建、实现用户故事。

Consequence(结果)

实现用户故事后，可以展示的结果。

并且总结为User Story的生命周期。

card->conversation->confirmation->construction->consequence->card…

卡片（Card）->交谈（Conversation）->确认（Confirmation）->构建（Construction）->结果（Consequence）-> 卡片（Card）…

用户故事的六个特性- INVEST

INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable

一个好的用户故事应该遵循INVEST原则。

独立性（Independent）—

要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。

可协商性（Negotiable）—

一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，    不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。

有价值（Valuable）—

每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。

可以估算性（Estimable）—

开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：    对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。

短小（Small）—
一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。

可测试性（Testable）—
一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

「用户故事」与敏捷、看板的使用流程

用“用户故事”方法描述的需求卡片会自始至终贯穿于整个开发流程。首先产品负责人根据收集来的需求编写用户故事，放入Product Backlog(产品待办列表)中。在Sprint Plan meeting(迭代计划会议)中，团队成员讨论其中的一些用户故事，细化故事细节，确定验收标准，使用Planning Poker(计划扑克)估算故事点。  然后将故事分成一些小的任务，并估算工作时间。

最后，将故事放入Sprint Backlog(迭代积压工作)中，并按优先级排序。Sprint(迭代)开时，故事卡片 和 任务卡片都放在白板的 To Do(待办)栏，团队成员按故事的优先级挑选任务，将任务卡片挪到Doing(正在进行)栏。任务完成后，将任务卡片挪到Done（已完成）栏。团队尽可能地先完成 优先级高的故事。在故事开发的初始阶段，测试人员和产品负责人一起确认测试用例。

故事的任务都完成后，产品负责人验收并确认故事已完成，将故事卡片挪到Done（已完成）栏。如此完成整个Sprint（迭代）的所有故事。Sprint（迭代）结束时，团队还要将完成的故事演示给利益相关人、其他产品负责人和团队等。这样，每个Sprint（迭代）团队都会通过完成一系列的用户故事来向客户输出商业价值。

附录:

参考文章

参考书籍：

《用户故事与敏捷方法》

《用户故事地图》

---

请关注微信公众号 【devopshub】，获取更多关于DevOps研发运维一体化的信息